
CONTENT DISTRIBUTION APPARATUS, CONTENT RECEIVING APPARATUS, AND 

CONTENT DISTRIBUTION METHOD 

BACKGROUND OF THE INVENTION 

5 

1. Field of the Invention 

The present invention relates to a content distribution 
apparatus, a content receiving apparatus, and a content 
distribution method- More particularly, it relates to technology 
10 in real-time distribution of content via an open network such as 
the Internet , whereby protection is provided against content theft 
by third parties and unauthorized copying of content by a content 
recipient , thereby enabling transmission and reception of content 
data while considering copyright protection. 

15 

2. Description of the Related Art 

In recent years , the digitization of the home sound and image 
(audio/visual; hereinafter abbreviated AV) environment, as 
exemplified by the start of digital broadcasts and the sales of 

20 digital AV equipment has gained much attention. Digital AV data 
enables diverse types of compression, is amenable to processing 
as multimedia data, tolerates unlimited playback without 
deterioration, and has other features which are expected to result 
in an expansion in its application in the future. 

25 On the other hand, digital AV data technology is accompanied 

by the problem of easy unauthorized copying of content. More 
specifically, any type of digital content can in principle be used 
to create a copy identical to the original and indefinitely durable , 
by means of bit copying, in the process of unauthorized content 

30 copying . 

A variety of technologies are being studied for the purpose 
of preventing unauthorized copying. One of these is the 139 4CP 
Content Protection System Specification being studied by the CPTWG 
( Content Protection Technical Working Group ) . In this technology , 
35 an authentication procedure is performed beforehand between 

sending and receiving nodes for content (such as MPEG data) to 
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be transferred between nodes connected by the IEEE 1394 bus, to 
enable shared use of an encryption key (content key) . Thereafter, 
this encryption key is used to encrypt the content and then encrypted 
content is transferred, and it is not possible for nodes other 
5 than the nodes that performed the authentication procedure to 
decrypt the content. By doing this, because a node other than 
the authenticated nodes (that is, a third party node) does not 
know the encryption key, even the node were able to capture the 
transferred data (that is, the encrypted content data), it would 

10 not be able to decrypt it. Nodes that can participate in this 
authentication procedure are limited to nodes that receive 
permission to do so by an authentication organization beforehand, 
thereby preventing an unauthorized node from obtaining the 
encryption key, and thus preventing unauthorized copying of 

15 content . 

The distribution of digital content is not , of course , limited 
to transfer via the IEEE 1394 bus , and general networks are expected 
to be used. The Internet is a strong candidate for building a 
technology infrastructure that is not wedded to public networks 

20 or physical/link networks. 

In conventional content distribution as practiced, however , 
digital content on the Internet (and in particular digital AV 
streams ) was mainly transferred in its raw form by the RTP (Real-time 
Transport Protocol) , without copyright protection provided by 

25 prevention of third-party theft and unauthorized copying by a 
recipient . 

SUMMARY OF THE INVENTION 

30 Accordingly, it is an object of the present invention, in 

consideration of the above-noted situation, to provide content 
distribution apparatus, a content receiving apparatus, and a 
content distribution method, which provide protection from copying 
when digital content is transferred on the Internet by real-time 

35 streaming. 

A feature of the present invention is that information with 
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regard to encryption and encoding etc. required to provide copy 
protection for digital content is efficiently appended as various 
headers to the content, making use of the characteristics of the 
Internet. 

5 One aspect of the present invention provides a content 

information distribution apparatus for distributing encrypted 
content information, via a network in accordance with a prescribed 
transport protocol, to other end apparatus in a communication 
authenticated by an authentication process including at least one 
10 procedure of an authentication procedure and a key exchange 
procedure, comprising: (a) a unit for encrypting content 
information encoded by a prescribed encoding system; (b) a unit 
|H for generating an encryption attribute header including attribute 

uJ information with regard to the encryption of the content 

rf 15 information; (c) a unit for performing transport protocol 
is*, processing required to transfer the content information and for 

*0 generating a basic transport header to be added to the content 

information towhich the encryption attribute header has beenadded; 
|T§ and (d) a unit for sending to the other end apparatus that is 

W 20 authenticated a packet including the basic transport header, the 
y encryption attribute header , and the encrypted content information , 

~ wherein the encryption attribute header is set into an expansion 

transport header within a packet header of the packet or into a 
payload header within a payload to be encrypted of the packet. 
25 It is preferable that the encryption attribute header 

includes at least one of the existence or non-existence of 
encryption of the content information and the encryption system 
of the content information. 

It is preferable that the encryption attribute header 
30 includes a copy attribute field having a plurality of bits with 
regard to the number of copying of the content information. 

It is preferable that the encryption attribute header 
includes a counter field indicating a change in an encryption key. 
It is preferable that the unit (b) sets the encoding 
35 information, which indicates the encoding system for the content 
information into the expansion transport header or into the payload 
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header . 

It is preferable that the unit (c) further codes into the 
basic transport header at least information to the effect that 
there is a possibility that the content information is encrypted, 
and wherein the unit (b) codes into the expansion header at least 
information as to whether or not the content information to be 
transferred is encrypted. 

It is preferable that the unit (b) codes into the expansion 
header information as to whether or not the content information 
to be transferred is encrypted. 

The above-noted content information distribution apparatus 
can further comprising: (e) a unit for generating a content 
attribute header that includes content attribute information with 
regard to content information, and for setting this content 
attribute header into the expansion transport header or into the 
payload header. 

The content attribute header need not be encrypted. 

The unit (a) generates the encryption key based on an 
identifier that uniquely identifies a storage medium sent from 
the other end apparatus in the communication. 

Another aspect of the present invention provides a content 
information receiving apparatus authenticated by an 
authentication process including at least one procedure of an 
authentication procedure and a key exchange procedure and which 
receives encrypted content information via a network in accordance 
with a prescribed transport protocol, comprising: (aa) a unit for 
receiving from a sending apparatus a packet containing a basic 
transport header, an encryption attribute header including 
attribute information with regard to the encryption of the content 
information, and encrypted content information; (bb) a unit for 
referring to the basic transport header or encryption attribute 
header and judging whether or not the content information is 
encrypted or whether there is a possibility that the content 
information is encrypted; and (cc) a unit that, when a judgment 
is made by the unit (bb) that the content information is encrypted, 
decrypts the encrypted content information, based on the attribute 



information with regard to encryption included in the encryption 
attribute header. 

It is preferable that the unit (bb), when there is a 
possibility that the content information is encrypted, refers to 
5 the encryption attribute header and judges whether or not the 
content information is encrypted. 

It is preferable that the unit (bb) refers to the basic 
transport header or to the encryption attribute header to make 
a judgment as to the encoding system of the content information. 

10 The above-noted apparatus can further comprising: (dd) a 

unit for referring to a received basic transport header and, when 
a prescribed delay time has elapsed or a prescribed number of packets 
have been discarded, requesting that the sending apparatus send 
a prescribed encryption parameter. 

15 Another aspect of the present invention provides a method 

of distributing encrypted content information, via a network in 
accordance with a prescribed transport protocol, to other end 
apparatus in a communication authenticated by an authentication 
process including at least one procedure of an authentication 

20 procedure and a key exchange procedure, comprising the steps of: 
(a) encrypting content information encoded by a prescribed encoding 
system; (b) adding an encryption attribute header including 
attribute information with regard to the encryption of the content 
information to the encrypted content information; (c) adding a 

25 content attribute header indicating attributes of the content 
information to content information to which the encryption 
attribute header has been added; (d) performing transport protocol 
processing required to transfer the content information , and adding 
a basic transport header to content information to which the content 

30 attribute header has been added; and (e) sending a packet including 
the basic transport header, the encryption attribute header, the 
content attribute header, and the encrypted content information 
to the other end authenticated apparatus, wherein the encryption 
attribute header is set into either an expansion transport header 

35 within a packet header of the packet, or into a payload header 
within an encrypted payload of the packet. 
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Another aspect of the present invention provides a method 
of distributing encrypted content information, via a network in 
accordance with a prescribed transport protocol , to other end 
apparatus in the communication authenticated by an authentication 
5 process including at least one procedure of an authentication 
procedure and a key exchange procedure, comprising the steps of: 
(a 1 ) adding a content attribute header indicating attributes of 
the content information to the content information to be 
transferred; (b' ) encrypting content information that are encoded 

10 by a prescribed encoding system and to which the content attribute 
header has been added; (c 1 ) adding to the encrypted content 
information an encryption attribute header including attribution 
information with regard to the encryption of the content 
information; (d') performing transport protocol processing 

15 required to transfer the content information, and adding a basic 
transport header to content information to which the encryption 
attribute header has been added; and ( e 1 ) sending a packet including 
the basic transport header, the encryption attribute header, the 
content attribute header, and the encrypted content information 

20 to the other end authenticated apparatus, wherein the encryption 
attribute header is set into either an expansion transport header 
within a packet header of the packet, or into a payload header 
within a payload to be encrypted of the packet . 

Another aspect of the present invention provides a method 

25 of receiving encrypted content information, via a network in 
accordance with a prescribed transport protocol, by an 
authentication process including at least one procedure of an 
authentication procedure and a key exchange procedure, comprising 
the steps of: (aa) receiving a packet including a basic transport 

30 header, an encryption attribute header including encryption 

attribute information with regard to the encryption of the content 
information, and encrypted content information; (bb) referring 
to the basic transport header and judging whether or not the content 
information is encrypted or whether or not there is a possibility 

35 that the content information is encrypted; (cc) referring to the 
encryption attribute header and extracting encryption attribute 
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information with regard to encryption of the content information; 
(dd) referring to an expansion transport header within a packet 
header of the packet and extracting content attribute information 
with regard to the content information; and (ee) in the case in 
5 which a judgment is made at (bb) that the content information is 
encrypted, decrypting the encrypted content information, based 
on the extracted encryption attribute information. 

Another aspect of the present invention provides a method 
of receiving encrypted content information, via a network in 
10 accordance with a prescribed transport protocol, by a 

authentication process including at least one procedure of an 
authentication procedure and a key exchange procedure, comprising 
the steps of: (aa 1 ) receiving a packet including a basic transport 
header, an encryption attribute header including encryption 
15 attribute information with regard to the encryption of the content 
information, and encrypted content information; (bb 1 ) referring 
to the basic transport header and judging whether or not the content 
information is encrypted or whether or not there is a possibility 
that the content information is encrypted; (cc") in the case in 
20 which a judgment is made at (bb 1 ) that the content information 
is encrypted, referring to the encryption attribute header and 
q extracting encryption attribute information with regard to the 

encryption of the content information; (dd* ) in the case in which 
a judgment is made at (bb • ) that the content information is encrypted, 
25 decrypting the encrypted content information based on the extracted 
encryption attribute information; and (ee 1 ) referring to an 
expansion transport header within a packet header of the packet 
and extracting content attribute information with regard to the 
content information . 
30 Another aspect of the present invention provides a 

computer- readable recording medium for recording a program to be 
executed by a computer, the program performing distribution of 
encrypted content information, via a network in accordance with 
a prescribed transport protocol, to other end apparatus in a 
35 communication authenticated by an authentication process 

including at least one procedure of an authentication procedure 
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and a key exchange procedure, the program comprising: (a) a module 
for generating an encryption attribute header including attribute 
information with regard to encryption of the content information; 
(b) a module for performing transport protocol processing required 
5 to transfer the content information and for generating a basic 
transport header to be added to the content information to which 
the encryption attribute header has been added; and (c) a module 
for sending a packet including the basic transport header, the 
encryption attribute header , and the encrypted content information 
10 to the other end authenticated apparatus, wherein the encryption 
attribute header is set either into an expansion transport header 

*pj within a packet header of the packet or into a payload header within 

IH a payload to be encrypted of the packet . 

^ Another aspect of the present invention provides a 

us % 

s!l 15 computer-readable recording medium for recording a program to be 

M, executed by a computer, the program performing receiving of 

*0 encrypted content information, via a network in accordance with 

e n ■ a prescribed transport protocol, by an authentication process 

hj including at least one procedure of an authentication procedure 

UJ 20 and a key exchange procedure , the program comprising: ( aa) a module 

Iff for receiving from a sending apparatus a packet including a basic 

r : 5 transport header, an encryption attribute header including 

attribute information with regard to encryption of the content 
information, and encrypted content information; (bb) referring 
25 to the basic transport header or the encryption attribute header 
and judging whether or not the content information is encrypted 
or whether there is a possibility that the content information 
is encrypted; and (cc) in the case in which a judgment is made 
by module (bb) that the content information is encrypted , decrypting 
30 the encrypted content information based on attribute information 
with regard to encryption included in the encryption attribute 
header. 

Other features and advantages of the present invention will 
become apparent from the following description taken in conjunction 
35 with the accompanying drawings. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings, which are incorporated in and 
constitute a part of the specification, illustrate presently 
5 preferred embodiments of the invention, and together with the 
general description given above and the detailed description of 
the preferred embodiments given below, serve to explain the 
principles of the invention, wherein: 

Fig. 1 is a drawing showing an example of a configuration 
10 of a network associated with the first embodiment to the sixth 
embodiment of the present invention ; 

Fig. 2 is a diagram showing an example of a sequence of content 
distribution in the first embodiment to the sixth embodiment of 
the present invention; 
15 Fig. 3 is a block diagram showing an example of the 

configuration of an MPEG distribution server according to the first 
*0 embodiment of the present invention; 

L_ Fig. 4 is a flowchart showing the procedure for content 

7j distribution processing in an MPEG distribution server according 

J 20 to the first embodiment of the present invention; 

ff Fig. 5 is a drawing showing a first example of a format of 

5 a code expansion header; 

Fig. 6 is a drawing showing a first example of the format 
of a header given by an RTP processor; 
25 Fig. 7 is a drawing showing a first example of a format of 

a transferred IP packet; 

Fig. 8 is a block diagram showing an example of the 
configuration of a receiving apparatus according to the first 
embodiment of the present invention; 
30 Fig. 9 is a flowchart showing the procedure for content 

receiving processing in a receiving apparatus according to the 
first embodiment of the present invention; 

Fig. 10 is a block diagram showing an example of the 
configuration of an MPEG distribution server according to the second, 
35 third, or fifth embodiment of the present invention; 

Fig. 11 is a drawing showing a second example of a format 
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of a header given by an RTP processor; 

Fig. 12 is a drawing showing the second example of the format 
of a transferred IP packet; 

Fig. 13 is a flowchart showing the procedure for content 
5 distribution processing in an MPEG distribution server according 
to the second embodiment of the present invention; 

Fig. 14 is a block diagram showing an example of the 
configuration of a receiving apparatus according to the second, 
third, or fifth embodiment of the present invention; 
10 Fig. 15 is a flowchart showing the procedure for content 

receiving processing in a receiving apparatus according to the 
second embodiment of the present invention; 

Fig. 16 is a drawing showing a third example of a format 
of a header given by an RTP processor; 
15 Fig. 17 is a drawing showing a third example of a format 

of a transferred IP packet; 

Fig. 18 is a block diagram showing an example of the 
configuration of an MPEG distribution server according to the fourth - 
or sixth embodiment of the present invention; 
20 Fig. 19 is a drawing showing a fourth example of a format 

of a header given by an RTP processor; 

Fig. 20 is a drawing showing a fourth example of a format 
of a transferred IP packet; 

Fig. 21 is a flowchart showing a procedure for content 
25 distribution processing in an MPEG distribution server according 
to the fourth embodiment of the present invention; 

Fig. 2 2 is a block diagram showing an example of the 
configuration of a receiving apparatus according to the fourth 
or sixth embodiment of the present invention; 
30 Fig. 23 is a flowchart showing a procedure for content 

receiving processing in a receiving apparatus according to the 
fourth embodiment of the present invention; 

Fig. 24 is a drawing showing a fifth example of a format 
of a header given by an RTP processor; 
35 Fig. 25 is a drawing showing a second example of a format 

of a code expansion header; 
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Fig. 26 is a drawing showing a fifth example of a format 
of a transferred IP packet; 

Fig, 27 is a drawing showing a sixth example of a format 
of a header given by an RTP processor; 
5 Fig. 28 is a drawing showing a sixth example of a format 

of a transferred IP packet; 

Fig. 29 is a drawing showing an example of the configuration 
of a network according to the seventh embodiment of the present 
invention; 

10 Fig. 30 is a drawing showing an example of the sequence of 

content distribution according to the seventh embodiment of the 
present invention; 

Fig. 31 is a block diagram showing an example of the 
configuration of an MPEG distribution server according to the 
15 seventh embodiment of the present invention; 

Fig. 32 is a drawing showing a seventh example of a format 
of a transferred IP packet; 

Fig. 33 is a drawing showing a seventh example of a format 
of a header given by an RPT processor; 
20 Fig. 3 4 is a block diagram showing an example of the 

configuration of a receiving apparatus according to the seventh 
embodiment of the present invention; and 

Fig. 35 is a drawing showing an example of the sequence of 
content distribution according to the eighth embodiment of the 
25 present invention. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Embodiments of a content distribution apparatus, a content 
30 receiving apparatus, and a content distribution method according 
to the present invention are described in detail below, with 
reference to Fig. 1 through Fig. 35. 

First Embodiment 

35 The first embodiment of a content distribution apparatus, 

a content receiving apparatus, and a content distribution method 
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according to the present invention is described in detail below, 
with reference to Fig. 1 through Fig. 9. 

Fig. 1 shows an example of the configuration of a content 
distribution system according to this embodiment of the present 
invention. In Fig. 1, an MPEG4 distribution server 101 and a 
receiving apparatus 102 according to this embodiment are connected 
to the Internet 10 3, MPEG 4 AV stream data being securely 
communicated between the MPEG4 distribution server 101 and the 
receiving apparatus 102, via the Internet 103. Of course, other 
MPEG 4 distribution servers and receiving apparatuses and other 
types of equipment can additionally be connected to the Internet 
103. 

In the description of embodiments to follow, while the type 
of data is MPEG (Motion Picture Experts Group) 4, it will be 
understood that the present invention is not restricted to 
application to this type of data, and can be applied to other data 
types as well. 

The MPEG 4 distribution server 101 performs distribution of 
MP EG 4 data to the receiving apparatus 102. MPEG4 data is 
distributed not in the form of file transfer, but rather as data 
stream. The MP EG 4 data that is to be copyright protected is 
distributed in encrypted form. When doing this , an authentication 
procedure or key exchange procedure is performed between the MPEG4 
distribution server 101 and the receiving apparatus 102. 

The sequence of this procedure is illustrated by example 
in Fig. 2. 

Fig. 2 shows the sequence of content layer encryption and 
authentication, and it should be noted that security in layers 
such as the IP layer and transport layer and authentication 
procedures in those layers have been omitted from this drawing, 
as has the procedure for assessing charges at the content layer, 
which is performed earlier (although there are cases in which charge 
assessment and authentication/encryption at other layers are not 
performed) . 

Consider the case in which the receiving apparatus 102 makes 
a request to the MPEG4 distribution server 101 for distribution. 
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In this case, the first authentication request is sent from the 
receiving apparatus 102 (S201) . In this authentication request, 
there can also be a simultaneous exchange of a certificate 
(equipment certification) that is received by the apparatus 
5 (receiving apparatus 102) from a certification organization, the 
certificate certifying that the equipment is capable of perf orming 
transfer of copyright protected content. 

The "equipment ID" that is used in the equipment certification 
can be an IP address, and in the case in which the IP address is 
10 given by a DHCP ( Dynamic Host Configuration Protocol ) server, there 
is a possibility that this value will differ each time the apparatus 
is booted. Because of this situation, it is possible to use as 
^1 the "equipment ID" for equipment certification the MAC address 

\ 5 * 

^ of the equipment, or the EUI64 address, or an address created by 

Ly 15 adding to these address a partial module number. It is further 

H[ possible to use as the "equipment ID" the CPU ID number of the 

apparatus, or the MPEG4 decoder ID number or the like, which 
□ (ideally) is a value that is unique worldwide (or that can be expected 

W to be unique or almost unique within the region). 

20 An MPEG4 distribution server 101 that receives a message 

#3 from the receiving apparatus 101, performs a response to the 

Q authentication request and performs exchange of a certificate 

(equipment certification) (S202). 

Next, the MPEG4 distribution server 101 and the receiving 
25 apparatus 102 perform a process that generates an authentication 
key, for the purpose of generating a common authentication key 
(S20 3) . Details of this procedure can be the same as, for example, 
the IEEE 139 4 copy protection key generation process. When this 
process is completed, the MPEG4 distribution server 101 and the 
30 receiving apparatus 102 can possess a common authentication key 
Kauth, which is not knowable to a third party. 

Next, the MPEG 4 distribution server 101 sends G(Kx, Kauth) 
which is generated by certain function G with the use of an exchange 
key Kx, the authentication key Kauth as arguments, and a random 
35 number Nc to the receiving apparatus 102 (S204, S205). At the 
receiving apparatus 102, reverse function of G(Kx, Kauth) is 
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calculated so as to extract the exchange key Kx. 

At this point in time, the MP EG 4 distribution server 101 
and the receiving apparatus 102 share the three values of 
authentication key Kauth, exchange key Kx, and the random number 
5 Nc. 

At this point, the encryption key (content ke y ) Kc, which 
is the encryption key for encrypting the MPEG4 data to be sent 
by the MPEG4 distribution server 101 and for the receiving apparatus 
102 to decrypt the received encrypted MP EG 4 data (that is the shared 

10 key) , is calculated in the MP EG 4 distribution server 101 and the 
receiving apparatus 102, respectively, by using one and the same 
pre-established function J , as a function of part of the above-noted 
value. For example, the calculation is made as Kc=J[Kx, f(EMI), 
Nc ] , in which EMI indicates the copy attribute for the data (content ) , 

15 which expresses such attributes as the data being copiable without 
limit, the data being copiable only 1 time, the data being copiable 
only 2 times , the data being uncopiable under any conditions , or 
the data being already copied and therefore not further copiable. 
f (EMI) is obtained by transf orming the attribute value of EMI with 

20 the use of certain specific function f . These functions J and 
f can also be kept maintained as secret with respect to the outside. 

After the encryption key (content key) Kc is generated, the 
MPEG 4 distribution server 101 encrypts the content (MPEG4 data) 
using the encryption key Kc, and sends the encrypted content to 

25 the Internet (S206, S207, . ..). 

As will be described below, because the encrypted content 
is in the form of AV stream data transferred in real time over 
the Internet, in the first embodiment of the present invention 
RTP (Real -time T ranspp i r B t_£r.qt-QCQ^ ) is used as the transport 

30 protocol. 

It is also possible to make the encryption key Kc vary with 
time (that is, have its value change with the passage of time). 

For example, if the elapse of a prescribed amount of time 
(which can be a fixed amount of time, or a variable amount of time) 
35 from the previous change is recognized, the value of the variable 
Nc is incremented, and the above-noted function J is used to 
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calculate the encryption key Kc. When this is done, the timing 
of updating of the encryption key Kc value (or the data at the 
point at which the encryption key Kc is to be updated) must be 
recognized synchronous ly at the sending and receiving sides. For 
5 this Reason, regions such as Even/Odd field is provided in the 
transferred MPEG4 data (AV data), and the point at which there 
is a change in the field is established as the point at which the 
value of the variable Nc, that is, the value of the encrypt ion 
ke y Kc is changed, so that data after the field ,j ghange_ point is 
10 er^rvpJ:jed M ,w.i-th,Jb_h J e^ u pdated. -.encr yp t ion key K c - 

The MP EG 4 distribution server 101 monitors the above-noted 
elapse of time and , when the timing for the updating of the encryption 
key Kc is detected, the value of the variable Nc is incremented 
and the encryption key Kc is calculated again, the recalculated 
15 value of the encryption key Kc being used to encrypt the MPEG4 
data that is to be sent , the Even/Odd field value being incremented , 
and transmission being performed. Thereafter, until the timing 
s for the next updating, this updated encryption key Kc is used to 

H; perform encryption. 

iVj 20 At the receiving apparatus 102, the received Even/Odd field 

O value is monitored, comparing the value with the immediately 

y previously received value and, if the value is detected as being 

different from the immediately previously received value, the value 
of the variable Nc is incremented, and the value of encryption 
25 key Kc is recalculated, the encryption key Kc after this 

recalculation being used in decrypting received encrypted data. 
Thereafter, until the next change in the Even/Odd field value is 
detected, this value of encryption key Kc is used to perform 
decryption. 

30 In this manner, encrypted MPEG 4 data is transferred between 

the MPEG 4 distribution server 101 and the receiving apparatus 102 . 

Fig. 3 shows an example of the internal configuration of 
the MP EG 4 distribution server 101. 

As shown in Fig. 3, the MP EG 4 distribution server 101 of 
35 this embodiment comprises a MPEG data generator 301, a data 

encryptor 302, an RTP processor 303, an RTCP transmitter 307, a 
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TCP/IP and UDP/IP processor 308, a link/physical layer processor 
309, an RCTP receiver/interpreter 310, and an authentication/key 
exchange processor 311. The RTP processor 303 includes an 
encryption expansio n heade r addin g unit 3 04 , an MPEG4 expansion 
5 h eadier adding unit J3 0 5 , and an RTP basic header adding unit 306, 
and performs processing related to the RTP. 

Next, the procedure for processing the content distribution 
in the MP EG 4 distribution server 101 according to the first 
embodiment is described below, with reference to Fig. 4. 
10 Processing related to authentication and encryption in the 

sequence of Fig. 2 (processing from S201 to S205) and processing 
£3 related to the above -described updating of the encryption key is 

?2 performed by the authentication/key exchange processor 311 . This 

u i 

isj processing can be performed before or after the sending of content 

y3 15 to the receiving apparatus 102. 

3:5 

;™ The inputted AV information (for example, an analog signal) 

!p is compressed to MP EG 4 data by the MPEG4 data generator 301. 

5 When this is done, if JV1PEG attribute information such as 

H the logcLfcion of I pictures (intra-coded pic tures) and jthe encojding^ 

Hi 20 ra te are sent simultaneously with the MPEG4 data to notify the 
Q receiving side, playback (decoding) at the receiving side is 

O facilitated. In particular on the Internet, where such things 

%srf as discarded and delayed packets and a change in the sequence of 

arrival of packets can occur, this attribute information is 
25 essential to achieve high-quality playback at the receiving side. 
For example, in the case of MPEG4 in the first embodiment, 
information about , for example , the VOP header corresponds to these 
attributes. Cases can be envisioned in which information with 
regard to the MPEG4 system, for example transmission of 
30 synchronization information at a sync layer, information for 
multiplexing when sending a plurality of MP EG 4 streams in 
multiplexed format , or information with regard to initial and latest 
values of object descriptors is required. For this reason, when 
sending AV data by RTP, the above-noted information is coded in to 
35 the RTP expansion header j ar^injbjCLJJiiB^^ 
payload ( that is , user are aJ__ t _soJthjLtJ^ 



16 



m 
id 



In the first embodiment, this MPEG attribute information 
is sent in the form of an RTP expansion header. That is f it is 
sent as an RTP expansion header of the ID type of MPEG 4 expansion 
5 header. For this reason, required information with regard to 
encoding is sent from the MPEG4 data generator 301 as notification 
to the MP EG 4 expansion header adding unit 305. 

Next , the MPEG4 data outputted from the MPEG 4 data generator 
301 is encrypted by the data encryptor 302 (step S401 in Fig. 4). 
10 When this is done , th ^ encr ypt ipn^kev L may be th e^above^noted 
t ime - va r i ant enc rypt ion key Kc. With regard to the encryption 
processing as well, a variety of attribute information can be 
envisioned. In the first embodiment , an RTP expansion header whose 
ID type indicates the encryp t ion _expans,ionJie.ader is added by the 
15 encryption expansion header adding unit 304 (step S403 ) . For this 
reason, information required for the generation of an encryption 
expansion header is sent as notification from the data encrypter 
5 302 to the encryption expansion header adding unit 304. 

Q In order to perform the above-noted encryption processing, 

fz 20 at the authentication/key exchange processor 311 when the timing 
p for updating the encryption key Kc is reached, Nc is incremented 

and the above -described function J is used to generate a new 
encryption key Kc which is passed to the data encrypter 302 . Along 
with this, the value of Even/Odd field is incremented and passed 
25 to the data encrypter 302. The value Even/Odd field is passed, 
as noted above, from the data encrypter 302 to the encryption 
expans ion header adding unit 304 . 

Fig. 5 shows an example of an en cryption expansion hejader . 
The encryption expansion header has a expansion header type field, 
30 a encryption on/off field, encryption type indication field, an 
encryption mode indicator (EMI) field, and an Even/Odd field. 

The expansion header type field is for coding information 
that indicates the type of corresponding expansion header. In 
this case, information that indicates the encryption expansion 
35 header is coded into the expansion header type field. 

The encryption on/off field is a field for coding information 
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indicating whether or not the data transferred in the corresponding 
RTP packet is encrypted. 

The encryption type indicator field is a field for coding 
the type of encryption used with respect to data transferred in 
5 an RTP packet. For example, in Fig. 5, information is described 
that indicates "an M6 encryption type". 

The encryption mode indicator (EMI) field is a field for 
coding the above-noted copy attribute value EMI. 

The Even/Odd field, as noted above, is a field for notifying 
10 the receiving side from the sending side of the timing of updating 
of the encryption key. 
□ Although in the example shown each field has 8 bits, there 

is no restriction to the number of bits, and the number of bits 
l\j can be appropriately established as desired. 

;=0 15 When AV data is encrypted and sent to the receiving side, 

p if it is desired to perform such trick play as fast -forwarding, 

[q or sending of partial static images, there are cases in which 

s processing at the receiving side becomes difficult. This is 

because it is difficult to perform a task such as sending just 
20 a part of an encrypted AV data stream (for example, because the 
g Nc value would not be incremented but would rather skip over a 

Q number of values ) . For this reason, in certain cases it is desirable 

hsS to send AV data to the receiving side without encrypting it. In 

such cases, it is necessary to notify the receiving side by 
25 information as to whether or not the AV data has been encrypted. 
The above-noted encryption on/off field is provided for such 
purposes . 

Additionally, on the Internet there is the possibility that 
one stream will use one encryption type and another stream use 
30 a different encryption type. In such cases, if there is a field 
' that indicates to what type of encryption the AV data has been 

subjected, the receiving side can examine this field so as to select 
a proper decryption engine for describing the data. The 
above-noted encryption type indicator field is provided for this 
35 type of purpose. 

As shown in Fig. 5, the encryption mode indicator (EMI) field 
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is 8 bits rather than the 2 bits that are used in the case of IEEE 
1394. This is in order to establish the freedom to select a value 
of N used to give notification of the specification of the number 
of copies N of the AV data that are to be permitted, and for cases 
5 in which a special type of copying (for example, permitting copying 
only when some condition is satisfied), in which case this field 
must be able to take a larger number of values than would be possible 
with 2 bits. 

As shown in Fig. 5, in the Even/Odd field, in contrast to 

10 the 1 bit used in IEEE 1394, there are 8 bits provided. This is 
because 1 bit would not allow enough information for the Internet, 
in which as noted above it is possible to have discarded or delayed 
packets and an altered sequence of packet arrivals- Thus, for 
example, on the Internet a case can be envisioned in which, with 

15 the Even/Odd bit las shown at step S20 7 , all the packets are discarded. 
In this case, if the Even/Odd field were to be just 1 bit, the 
Even/Odd field would return to 0 at the next packet, so that as 
seen from the receiving side the condition in which the Even/ Odd 
bit is 0 is continuing (that is, not changing). Thus, although 

20 Nc should actually be incremented by 2, if the Even/Odd bit value 
is not changed, the Nc value is not incremented, thereby preventing 
generation of the correct encryption key. Because of this 
situation, more than 2 bits, for example 8 bits, are provided in 
the Even/Odd field, so that even if packet discarding and delay, 

25 or resequencing of packet arrival occurs , as it can on the Internet , 
it is possible to perform appropriate processing on the receiving 
side. 

In the first embodiment of the present invention, data 
encryption is performed only with respect to MP EG 4 data itself, 

30 and not with respect to the MPEG4 expansion header. Because the 
MP EG 4 expansion header is not content that need to be copyright 
protected, but is rather used on the receiving side before the 
MPEG 4 data itself is used, enabling it to omitted from the data 
that is encrypted . 

35 In the RTP processor 303, an encryption expansion header 

is added to the MP EG 4 data by the encryption expansion header adding 



19 



unit 304, an MPEG4 expansion header is added to the MP EG 4 data 
by the MP EG 4 expansion header adding unit 305 (step S405 in Fig. 
4) , and an RTP basic header is added to the MP EG 4 data by the RTP 
basic header adding unit 306 (stepS407), the ultimate result being 
the addition of the RTP header such as shown in Fig. 6. The 




Encrypted MPEG4 data to which the RTP header has been added 
is sent to the Internet 103 by the TCP/IP and UDP/IP processor 
308 as an IP packet as shown in Fig. 7, via the link/physical layer 
processor 309. 



Next, the configuration of the receiving apparatus 102 and 
the procedure for processing therein will be described. 

Fig. 8 shows the internal configuration of the receiving 
apparatus 102. 

As shown in Fig. 8, the receiving apparatus 102 according 
to the first embodiment comprises a link/physical layer processor 
701, a TCP/IP and UDP/IP processor 702, an RTP processor 703, a 
data encryptor/decryptor 707 , an MPEG4 data decoder 708 , a receiving 
condition interpreter 709, an RTCP transmitter 710, and an 
authentication/key exchange processor 711. The RTP processor 703 
includes an RTP basic header receiver/ interpreter 704, an MPEG4 
expansion header receiver/interpreter 705, and an encryption 
expansion header receiver/interpreter 706, and performs 
processing related to the RTP. 

Fig. 9 shows a procedure for encrypted content receiving 
processing performed by the receiving apparatus 102 of the first 
embodiment of the present invention. 

Processing related to authentication and encryption of the 
sequence of Fig. 2 (processing from S201 to S205) and processing 
related to encryption key updating is performed by the 
authentication/key exchange processor 711. 
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The receiving apparatus 102 basically performs processing 
in a sequence that is the reverse of the processing performed by 
the MPEG4 distribution server 101. 

Specifically, MPEG4 data (encrypted data with an added RTP 
header) transferred via the Internet 103 passes through the 
link/physical layer processor 701 to the TCP/IP and UDP/IP processor 
702 and is then inputted to the RTP processor 703 (step S901 in 
Fig. 9). 

At the RTP processor 703 , the RTP basic header is interpreted 
by the RTP basic header receiver/interpreter 704 (step S903 in 
Fig. 9), the MPEG4 expansion header is interpreted by the MPEG4 
expansion header receiver/interpreter 705 (Step S905), and the 
encryption expansion header is interpreted by the encryption 
expansion header receiver/interpreter 706 (Step S907). 
Information required for decoding is sent as notification from 
the MP EG 4 expansion header receiver/interpreter 705 to the MPEG 4 
data decoder 708, and information required for decryption is sent 
from the encryption expansion header receiver/interpreter 706 to 
the data encyptor/decryptor 707. 

The encrypted data stored in the RTP payload is passed from 
the RTP processor 703 to the data encryptor/decryptor 707. The 
data encryptor/decryptor 70 7 performs decryption of data, based 
on information from the encryption expansion header 
receiver /interpreter 70 6 . 

The encryption key used in decryption is the above -de scribed 
time-variant encryption key Kc. That is, the data 
encryptor/decryptor 70 7 refers to a value of the encryption on/off 
field of the encryption expansion header sent as notification from 
the encryption expansion receiver/interpreter 706, so as to learn 
that the received data is encrypted (as a result of which the 
decryption thereof is determined) , after which the Even/Odd field 
is referenced and a comparison is made between the value thereof 
and a previously received value. If the value had been an increment , 
it is known that the encryption key is to be updated (but if the 
values are the same , the encryption key will not be updated) . Then , 
the fact that the encryption key is to be updated is notified to 
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the authentication/key. exchange processor 711 from the data 
encryptor/decryptor 707, and in the authentication/key exchange 
processor 711 since the timing for updating the encryption key 
Kc has been reached, Nc is incremented and the above-noted function 
J is used to generate a new encryption key Kc, which is passed 
to the data encryptor/decryptor 707. 

Decrypted MP EG 4 data is passed from the data 
encryptor/decryptor 707 to the MP EG 4 data decoder 708 - The MP EG 4 
data decoder 708 decodes this MPEG4 data, based on information 
from the MP EG 4 expansion header receiver/ interpreter 705, and 
outputs the results as an AV output data (for example, an analog 
signal) . 

In the above, the RTP has associated with it RTCP (Real-time 
Transport Control Protocol) . RTCP monitors the RTP sequence 
number and time stamp and has the function of notifying the sending 
side (in the first embodiment, the MPEG4 distribution server 101) 
from the receiving side (in the first embodiment, the receiving 
apparatus 102) with regard to the receiving condition (packet 
discarding rate, packet transmission delay time, and the like). 
This is performed by the receiving condition interpreter 709 and 
the RTCP transmitter 710. 

The MPEG4 distribution server 101 receives this RTCP packet 
at the RTCP receiver/interpreter 310 and, if necessary, can apply 
feedback to the MPEG4 data generator 301, to attempt to achieve 
optimization. For example, in the case in which there is a great 
amount of packet discarding, network crowding can be envisioned, 
in response to which the bit rate of the MPEG4 data generation 
can be lowered by feedback. 

The RTCP transmitter 307 of the MPEG4 distribution server 
101 transmits information required for RTCP. 

On the other hand, as described above, in the receiving 
apparatus 102 based on the results of monitoring the Even/Odd field 
included in the encryption expansion header of the received packet , 
the value of the variable Nc used in the calculation of the encryption 
key Kc is changed. Therefore, if it is not possible for the sending 
side to reliably inform the receiving side that the value of Nc 
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has been updated , the receiving side cannot calculate the encrypt ion 
key Kc, thereby making it impossible to decrypt the arriving 
encrypted data. 

Because the Internet is intrinsically a network on which 
discarding of packets can occur, it is not guaranteed that the 
meaning of the Even/Odd field value (timing of incrementing) will 
be accurately informed to the other apparatus in a communication 
link (particularly in the case in which there are few bits in the 
Even/Odd field) . Because of this situation, in the case in which 
the receiving apparatus 102 wishes to know the precise value of 
Nc, it can be provided with the option to issue a request to the 
sending apparatus (in this embodiment, the MPEG4 distribution 
server 101) for the Nc value. 

As an example of a case in which the receiving apparatus 
102 wishes to know the precise Nc value, consider the case in which 
there is more skipping than expected in the time stamp or the sequence 
number of the RTP basic header, in which case one solution 
envisionable is that of sending a packet to the sending side to 
request the value of Nc. This is because a skip greater than a 
pre-established limit could mean the possibility that the Even/Odd 
bit value has changed. This processing is performed by the 
authentication/key exchange processor 311 of the MPEG4 
distribution server 101 or the authentication/key exchange 
processor 711 of the receiving apparatus 102. By doing this, even 
in the event that synchronization of the Even/Odd bit is lost between 
the MPEG4 distribution server 101 and the receiving apparatus 102, 
it is possible to perform appropriate recovery processing. 
Furthermore, in the case in which there is notification of Nc value 
from the MP EG 4 distribution server 101 to the receiving apparatus 
102, it is possible to simultaneously send the time stamps and 
sequence numbers of the corresponding RTP, expansion header, or 
payload header as notification. 

A case can be envisioned in which distributed data is 
accumulated in the receiving apparatus (or in some form of storage 
medium, such as DVD-RAM or the. like, installed in the receiving 
apparatus), in which case the distributed data can be stored as 
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is in the form of encrypted data, and the corresponding encryption 
key Kc stored together therewith. 

Second Embodiment 

Next , the second embodiment , in which there is a variation 
of the packet format in the first embodiment, is described below, 
with reference to Fig. 10 through Fig. 15. Because the basic 
configuration and operation of the second embodiment is the same 
as that of the first embodiment, the description that follows 
focuses on the differences introduced with the second embodiment 
compared to the first embodiment. 

The difference in the second embodiment with respect to the 
first is that, whereas in the first embodiment an encryption 
expansion header andMPEG4 expansion header were added as expansion 
header in an RTP header (Fig. 6 and Fig. 7) , in the second embodiment 
the encryption expansion header is added as the expansion header 
in the RTP header and the MPEG4 expansion header is added as a 
payload header to the RTP payload (Fig. 11 and Fig. 12). 

The overall network configuration according to the second 
embodiment is similar to that of the first embodiment (Fig. 1). 
The processing sequence is also similar to that of the first 
embodiment (Fig. 2). The encryption expansion header format is 
also similar to that of the first embodiment (Fig. 5). 

Fig. 10 shows an example of the configuration of an MPEG 4 
distribution server 101 according to the second embodiment. In 
this embodiment, because the MPEG4 expansion header is provided 
as a payload header for the RTP payload , the processing for applying 
the MP EG 4 header is removed from the RTP processing, so that the 
MP EG 4 expansion header adding unit 305 of Fig. 3 is removed from 
within the RTP processor 305 and placed outside, this becoming 
the MPEG 4 payload header adding unit 315, which is different than 
in the first embodiment. 

Fig. 11 shows the format of the RTP header used when sending 
encrypted AV data in the second embodiment. In the second 
embodiment, a payload type field that indicates an attribute of 
data that is transferred by an RTP packet (for example, encoding 
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system) is provided ia the RTP basic header- In the second 
embodiment , for example, if the transferred data is encrypted MPEG4 
data, this field will be coded with information indicating "the 
data is encrypted MPEG4 data" . The receiving apparatus 102 can 
know that transferred data is encrypted MPEG 4 data with reference 
to this field- 
Additionally in the second embodiment, the RTP basic header 
is provided with an X bit field that indicates whether or not there 
is an expansion header added to the RTP header- In the second 
embodiment , the arrangement is that a bit indicating "the existence 
of an expansion header" is set. 

Fig. 12 shows tihe overall format of an IP packet transferred 
over the Internet by the second embodiment. 

Fig. 13 is a flowchart shows the procedure for processing 
of content distribution in the second embodiment of the present 
invention. In this second embodiment, first the MPEG4 payload 
header adding unit 315 adds an MPEG4 payload header to the content 
(step S400) , the step S405 shown in Fig. 4 not being carried out. 
The processing of the other steps S401, S403, S407, and S409 is 
similar to the processing as described with regard to the first 
embodiment. However, the header has the above-noted information 
set into it. 

Next, the receiving apparatus 102 according to the second 
embodiment is described below. 

Fig. 14 shows an example of the configuration of the receiving 
apparatus 102 of the second embodiment . Similar to the above-noted 
MP EG 4 distribution server 101 , the processing of theMPEG4 expansion 
header is moved to outside of the RTP processor, the MP EG 4 expansion 
header receiver/ interpreter 705 of Fig. 8 being moved from inside 
the RTP processor 703 to outside, this becoming the MP EG 4 payload 
header receiver/interpreter 715, which is different than in the 
first embodiment. 

Fig. 15 is a flowchart showing the procedure for receiving 
processing in a receiving apparatus 102 according to the second 
embodiment . 

At the receiving apparatus 102, first a packet is received 
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(step S901) , and at the RTP basic header receiver/ interpreter 704 
it is learned that the received data is encrypted MPEG 4 data and 
that an expansion header has been added to the RTP header (step 
S903). Then, at the expansion header receiver/interpreter 706 
it is learned that the expansion header is an encryption expansion 
header, and possible to learn from the encryption expansion header 
the encryption system and whether or not there is updating of the 
encryption key (step S907) . Then, similar to the case of the first 
embodiment, at the data encryptor/decryptor 70 7 the encrypted MPEG4 
data is decrypted (step S909), and at the MPEG payload header 
receiver/interpreter 715 the MPEG4 payload header is interpreted 
(step S910), and further, similar to the first embodiment, at the 
MPEG4 data generator 708, MPEG4 data is decoded, based on the results 
of the above interpreting, the results being output ted as an AV 
output data (for example, an analog signal). 

In this second embodiment, in the case in which the payload 
type field is coded with information that includes notification 
of encryption, the encryption on/off field of the encryption 
expansion header need not be referenced, and in the case in which 
the payload type field is coded with information that includes 
notification of the encryption, this can be taken as a notification 
of the possibility of encryption, so that encryption on/off field 
in the encryption expansion header can be used for the final 
determination of whether or not there is encryption. 

Third Embodiment 

Next, the third embodiment of the present invention is 
described in detail below, with reference to Fig. 16 and Fig. 17. 
In this embodiment, the description will focus on differences with 
respect to the second embodiment. 

The configuration and processing in the third embodiment 
are similar to those of the third embodiment. 

Fig. 16 shows the format of the RTP header format used in 
transmitting encrypted AV data in the third embodiment, and Fig. 
17 shows the overall IP packet format transferred via the Internet 
in the third embodiment . 
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Specifically, whereas in the second embodiment, in the 
payload type field within the RTP basic header information was 
coded that provides notification of the existence of encryption 
or the possibility of encryption, such as "encrypted MPEG 4 data" , 
in the third embodiment, only "MPEG 4" is coded, and information 
including notification of encrypting or the possibility thereof 
is not coded in the payload type field. 

In ±he third embodiment, therefore, while the receiving 
apparatus 102 can refer to the payload type field to know that 
the received data is MP EG 4 data, recognition with regard to whether 
or not there is encryption is done by referencing the RTP expansion 
header (the encryption expansion header) of the RTP header. 

In the receiving apparatus 102, at the RTP basic header 
receiver/ interpreter 70 4 it is learned that the received data is 
MP EG 4 data, and that an expansion header is added to the RTP header. 
Then , at the encryption expansion header receiver/interpreter 706 , 
it is learned that the expansion header is an encryption expansion 
header, and it is possible to learn from the encryption expansion 
header whether or not there is encryption and whether or not the 
encryption key is updated. Thereafter, the processing is the same 
as in the second embodiment . 

Fourth Embodiment 

Next, the fourth embodiment of the present invention is 
described below with reference to Fig. 18 to Fig. 23, focusing 
on the difference between it and the second embodiment. 

The difference between the fourth embodiment and the second 
embodiment is that , whereas in the second embodiment the encryption 
expansion header is added to the expansion header of the RTP header 
and the MPEG4 expansion header is provided as a payload header 
of the RTP payload (Fig. 11 and Fig. 12) , in the fourth embodiment, 
both the encryption expansion header and the MPEG4 expansion header 
are provided as a payload header in the RTP payload (Fig. 19 and 
Fig. 20). 

The overall configuration of a network according to the fourth 
embodiment is similar to that of an above-noted embodiment (Fig. 
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1) , and the processing sequence is also similar to an above-noted 
embodiment ( Fig . 2 ) . The format of the encryption expansion header 
(encryption payload header in the fourth embodiment) is also the 
same as described above (Fig. 5). 

Fig. 18 shows an example of the configuration of an MPEG4 
distribution server 101 according to the fourth embodiment. In 
this embodiment, because the encryption expansion header added 
to the MP EG 4 expansion header is also provided as a payload header 
in the RTP payload, the processing for the encryption expansion 
header is placed outside the RTP processor, and the encryption 
expansion header adding unit 304 of Fig. 10 is also moved from 
within the RTP processor 304 to outside, this serving as the 
encryption payload header adding unit 314, which is a difference 
with respect to the second embodiment. 

Fig. 21 is a flowchart showing the procedure for content 
distribution processing according to the fourth embodiment. In 
the fourth embodiment , in place of step S403 of Fig. 13, an encryption 
payload header adding unit 314 adds an encryption payload header 
to the encrypted MPEG4 data (step 403b) . The processing at other 
steps S400, S401, S407, and S409 are similar to that described 
with regard to the above embodiment, with the exception that the 
above-noted information is set into the header. 

Fig. 19 shows the format of the RTP header used in transmission 
of encrypted AV data in the fourth embodiment. With regard to 
the payload type field, the fourth embodiment is similar to the 
second embodiment. The function of the X bit field is similar 
to that in the second embodiment , and in this embodiment the 
arrangement is that a bit indicating "no expansion header (no RTP 
expansion header)" is set. 

Fig. 20 shows the overall format of an IP packet transferred 
via the Internet in the fourth embodiment. 

Fig. 22 shows an example of the configuration of a receiving 
apparatus 102 according to the fourth embodiment. Similar to the 
case of the above-noted MPEG4 distribution server 101, the 
processing of the encryption expansion header is moved to outside 
the RTP processor, and the encryption expansion header receiver 
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/interpreter 706 of Fig. 11 is moved from within the RTP processor 
703 to outside, this serving as the encryption pay load header 
receiver/interpreter 716, which is a difference with respect to 
the second embodiment. 

Fig. 23 shows the procedure for receiving processing in the 
receiving apparatus 102 in the fourth embodiment . In the receiving 
apparatus 102, first a packet is received (step S901) , and at the 
RTP basic header receiver/interpreter 704 it is learned that the 
received data is encrypted MPEG4 dat a , and learned that no expansion 
header is added to the RTP header (step S90 3) . In this embodiment, 
subsequent processing is processing for the payload. First at 
the encryption payload receiver/interpreter 716 it is learned that 
the payload is an encryption expansion header, and it is also 
possible to learn from the encryption payload header such 
information as the encryption system and whether the encryption 
key is updated (step S907b) . Subsequent processing is similar 
to the case of the second embodiment, the encrypted MPEG4 data 
being decrypted at the data encryptor/decryptor 707 (step S909), 
the MPEG4 payload header being interpreted at the MPEG 4 payload 
header receiver/interpreter 715 (step S910) , the MPEG4 data being 
decoded at the MP EG 4 data generator 708, based on the above 
interpretation results, and the results of this being output as 
an AV output data (for example, an analog signal). 

Similar to the case of the second embodiment , in the fourth 
embodiment in a case in which information including notification 
of encryption is coded into the payload header, it is not necessary 
to refer to the encryption on/off field of the encryption payload 
header, and if information including notification of encryption 
is coded into the payload type field, this can be taken as a 
notification of the possibility of encryption, so that the 
encryption on/off field of the encryption payload header can be 
used for the final determination of whether or not there is 
encryption. 

Fifth Embodiment 

Next, the fifth embodiment of the present invention is 
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described below, with -reference to Fig. 24 through Fig. 26, the 
description thereof focusing on the difference with respect to 
the second embodiment. 

Fig. 24 shows the format of the RTP header used when 
transmitting encrypted AV data in the fifth embodiment. Fig. 25 
shows the format of the encryption expansion header in the fifth 
embodiment, and Fig. 26 shows the overall IP packet transferred 
via the Internet in the fifth embodiment. 

Whereas in the second embodiment information including 
notification of encrypted data attributes (for example, encoding 
system) such as "encrypted MPEG4" was coded into the payload type 
field within the RTP basic header (Fig. 11 and Fig. 12), in the 
fifth embodiment only information giving notification of the fact 
that the data is encrypted (for example, "encrypted data" ) is coded 
into the payload type header (Fig. 24 and Fig. 26). While the 
addition of an encryption expansion header as an expansion header 
to the RTP header, and the provision of an MP EG 4 expansion header 
as a payload header to the RTP payload are the same as with the 
second embodiment, in the fifth embodiment the above-noted 
encrypted data attributes (encoding system or the like) are coded 
into the encryption expansion header (Fig. 5 and Fig. 25). 

The overall configuration of the network according to the 
fifth embodiment is similar to that of an above-noted embodiment 
(Fig. 1), and the sequence of processing is also similar to an 
above-noted embodiment (Fig. 2) . The internal configurations of 
the MPEG 4 distribution server 101 and the receiving apparatus 102 
are also similar to those of the second embodiment (Fig. 11 and 
Fig. 13). 

As shown in Fig. 24, in the fifth embodiment a value indicating 
"encrypted data" is coded into the payload type field of the RTP 
basic header. The receiving apparatus 102 can refer this field 
to learn that the transferred data is encrypted. In the fifth 
embodiment, the X bit field has a bit that indicates "there is 
an expansion header". 

As shown in Fig. 25, in the fifth embodiment, a payload type 
field is provided in the encryption expansion header . Information 
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indicating the type of data (MPEG4 in this embodiment ) in the payload 
is coded into the payload type field. The receiving apparatus 
102 can refer to this field to learn the type of data transferred. 

In the receiving apparatus 102, at the RTP basic header 
receiver/interpreter 704 it is learned that the received data is 
encrypted data, and that there is an expansion header added to 
the RTP header- Then, at the encryption expansion header 
receiver/interpreter 706 is it learned that this expansion header 
is an encryption expansion header , and from the encryption expansion 
header it is possible to learn such information as the encryption 
system, whether or not the encryption key is updated, and the type 
of data in the payload. Similar to the case of the second embodiment , 
the encrypted MP EG 4 data is decrypted at the data 
encryptor/decryptor 707, the MPEG4 payload header is interpreted 
at the MPEG4 payload header receiver/interpreter 715 , at the MPEG4 
data generator the MPEG4 data is decoded based on the results of 
the above interpretation, and the results are output as an AV output 
data (for example, an analog signal). 

In the fifth embodiment, similar to the case of the second 
embodiment , in the case in which information including notification 
of encryption is coded into the payload type field, it is not 
necessary to refer to the encryption on/off field of the encryption 
expansion header, and if information including notification of 
encryption is coded into the payload type field in the RTP basic 
header, this can be taken as a notification of the possibility 
of encryption, so that the encryption on/off field of the encryption 
expansion header can be used for the final determination of whether 
or not there is encryption. 

Sixth Embodiment 

Next, the sixth embodiment of the present invention is 
described below with reference to Fig. 27 and Fig. 28, the 
description focusing on the difference with respect to the fourth 
embodiment . 

Fig. 2 7 shows the format of the RTP header used when 
transmitting encrypted AV data in the sixth embodiment. The 
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encryption expansion header of this embodiment is similar to that 
shown in Fig. 25 . Fig. 28 shows the overall format of an IP packet 
transferred via the Internet in the sixth embodiment. 

That both the encryption expansion header and the MPEG4 
expansion header are provided as an RTP payload header is similar 
to the fourth embodiment (Fig. 19 and Fig. 20) . However, in contrast 
to the fourth embodiment, wherein information including 
notification of attributes of encrypted data, such as the encoding 
system, for example, "encrypted MPEG4 " are coded into the payload 
type field within the RTP basic header, in the sixth embodiment, 
only information giving notification about the existence of 
encryption (such as "encrypted data") is coded into the payload 
type field (Fig. 27 and Fig. 28) . Additionally, while the fact 
that an encryption expansion header is added as an expansion header 
of the RTP header, and an MPEG4 expansion header is added as a 
payload header to the RTP payload are the same as in the second 
embodiment , in the sixth embodiment the above-noted encrypted data 
attributes (for example, encoding system) are coded within the 
encryption expansion header (Fig. 5 and Fig. 25) 

The overall configuration of the network according to the 
sixth embodiment is similar to an above -noted embodiment (Fig. 
1) , and the sequence of processing is also similar to an above-noted 
embodiment (Fig. 2). The internal configuration of the MPEG4 
distribution server 101 and the receiving apparatus 102 are also 
similar to those of the fourth embodiment (Fig. 18 and Fig. 22). 

As shown in Fig. 27 , in the sixth embodiment a value indicating 
"encrypted data" is entered into the payload type field of the 
RTP basic header. By referring to this field, the receiving 
apparatus 102 can know that the transferred data is encrypted data. 
The X bit field has a bit that indicates "there is no expansion 
header" . Similar to the case of the fourth embodiment , information 
indicating the type of data in the payload (MPEG4 in this embodiment ) 
is coded into the payload type field of the encryption expansion 
header. 

In the receiving apparatus 102, at the RTP basic header 
receiver/interpreter 70 4 it is learned that the received data is 
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encrypted, and it is learned that no expansion header is added 
to the RTP header. In the sixth embodiment , subsequent processing 
is with respect to the payload. First, at the encryption payload 
receiver/ interpreter 716 it is learned that the payload header 
is an encryption expansion header, and it is possible to learn 
from the encryption payload head such information as the encryption 
system, whether the encryption key is updated, and type of data 
in the payload. In the same manner as in the fourth embodiment, 
at the data encryptor/ decrypt or 707 the encrypted MPEG4 data is 
decrypted, at the MPEG payload header receiver/ interpreter 715 
the MPEG4 payload header is interpreted , at the MPEG4 data generator 
708 the MPEG 4 data :is decoded based on results of the above 
interpretation, the results being output as an AV output data (for 
example, an analog signal). 

In the sixth embodiment, similar to the case of the fourth 
embodiment , in the case in which information including notification 
of encryption is coded into the payload type field of the RTP basic 
header, it is not necessary to refer to the encryption on/off field 
in the encryption expansion header, and if information including 
notification of encryption is coded into the payload type field, 
this can be taken as a notification of the possibility of encryption, 
so that the encryption on/off field of the encryption expansion 
header can be used for the final determination of whether or not 
there is encryption. 

Seventh Embodiment 

Whereas in the first embodiment to the sixth embodiment, 
the present invention was applied to a system in which RTP was 
used as a transport protocol, the present invention can also be 
applied to systems using other protocols. 

In the seventh embodiment, instead of using RTP as the 
transport protocol, the distribution of MP EG 4 data is performed 
using HTTP (Hyper-Text Transfer Protocol), that is, a protocol 
for use between WWW servers and Web browsers. 

Fig. 29 shows an example of the configuration of an 
information distribution system in the seventh embodiment. In 
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system shown in Fig . 29 .. anMPEG4 distribution server 6101 according 
to the seventh embodiment is connected to the Internet 103. and 
a receiving apparatus 6102 according to the seventh embodiment 
is connected to a LAN 6105, the LAN 6105 being connected to the 
Internet 103 via a proxy server 6104. The receiving apparatus 
6102 performs AV stream communication secretly with the MPEG4 
distribution server 6101. via the LAN 6105. the proxy server 6104 
and the Internet 103 . Of course . other MPEG 4 distribution servers 
and other types of equipment can also be connected to the Internet 
103, and other receiving apparatuses and other types of equipment 
can also be connected to the LAN 6105. 

Although in the seventh embodiment, the description is that 
of the case in which the data type is MPEG4. it will be understood, 
of course, that the present invention is not restricted to this 
15 type of data. 

In Fig. 29. the various equipment supports IP. However, 
because of the HTTP proxy server 6104 between the LAN 6105 and 
the Internet 103. the IP address on the LAN 6105 can be either 
a global IP address or a private (local) IP address. The term 
proxy server as used herein refers to a server that at one point 
terminates HTTP (or some other protocol) between the Internet and 
an intranet, and functions so as to join HTTP sessions at both 
ends of the proxy server, and is provided to enable the distribution 
of HTTP content data requested by substantial receiving apparatus 
(Web browser) to a distribution server (Web server) , and functions 
in the reverse direction as well. Details about proxy servers 
canbefoundat, for example, the URL http : //squid, nlanr. net/Squid. 
In the seventh embodiment, the MPEG 4 distribution server 6101 can 
be a WWW server, and the receiving apparatus 6102 can also be a 
30 browser . 

Fig. 30 shows an example of the sequence of the authentication 
process, key exchange process, and encrypted data transmission. 
Because the proxy server 6104 is disposed between the receiving 
apparatus 6102 and the MPEG4 distribution server 6101. the actual 
messages (messages transferred as HTTP messages) are in reality 
relayed via the proxy server 6104, this being the only difference 
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with respect to previously described embodiments (Fig. 2), with 
other elements of the procedure being the same as previously 
described procedures. 

With regard to the MPEG4 distribution server 6101, the 
receiving apparatus 6102. the packet format, if parts of the units 
in the first through the sixth embodiments dependent upon the 
transport protocol are modified to accommodate the HTTP protocol, 
it is possible to configure an MPEG4 distribution server 6101, 
a receiving apparatus 6102, and a packet format conforming to the 
HTTP protocol. In the following, the example is that in which 
an encryption expansion header is added as an expansion header, 
and in which an MPEG4 expansion header is provided as a payload 
header (as in the second embodiment). 

Fig. 31 shows the internal configuration of the MPEG4 
distribution server 6101. 

As shown in Fig. 31, the MPEG4 distribution server 6101 
according to the seventh embodiment comprises an MPEG4 data 
generator 6301, a data encrypter 6302. an MPEG4 payload header 
adding unit 6305 , an HTTP processor 6303 that includes an encryption 
header adding unit 6304 and a MIME header adding unit 6306 , a TCP /IP 
and UDP/IP processor 6308, a link/physical layer processor 6309, 
and an authentication/key exchange processor 6311. 

Processing related to authentication and encryption of the 
sequence shown in Fig. 30 (from S6201 to S6205) and processing 
related to encryption key updating is performed by the 
authentication/key exchange processor 6311. 

The HTTP processor 6303 corresponds to the RTP processor 
in previously described embodiments, and the MIME (Multipurpose 
Internet Mail Extensions) header adding unit 6306 corresponds to 
the RTP basic header adding unit in previously described 
embodiments. 

Fig. 32 shows an IP packet that is transferred on the Internet 
(and LAN), and Fig. 33 shows details of the MIME basic header and 
encryption expansion header. 

In the seventh embodiment , the encryption expansion header 
is transferred as part of the MIME. For this reason, with regard 
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to the encryption expansion header, information indicating that 
"this is an encryption expansion header" is coded into the 
Content-Type of the MIME. The MPEG4 expansion header is 
transferred as part of the MIME, along with the encrypted MPEG4 
data as payload header. For the encrypted MP EG 4 data to which 
MPEG 4 expansion header added, information indicating that "this 
is MPEG4 data" is coded into the MIME Content -Type . For details 
with regard to MIME, refer to RFC 204 5, for example. 

The format of the encryption expansion header is the same 
as was described for the first embodiment. 

Fig. 34 shows an example of the internal configuration of 
the receiving apparatus 6102. 

As shown in Fig. 34, the receiving apparatus 6102 according 
to the seventh embodiment comprises a link/physical layer processor 
6701, a TCP/IP and UDP/IP processor 6702, an HTTP processor 6703 
that includes a MIME header interpreter 6 704 and an encryption 
header interpreter 6706 , an MP EG 4 payload header interpreter 6705 , 
a data encrypt or/ decrypt or 6707, an MP EG 4 data decoder 6708, and 
an authentication/key exchange processor 6711. 

Processing related to authentication and encryption in the 
sequence of Fig. 30 (processing from S6201 to S6205 ) and processing 
related to encryption key updating is performed by the 
authentication/key exchange processor 6711. 

The HTTP processor 6703 corresponds to the RTP processor 
shown in the above-described embodiments, and the MIME header 
interpreter 6704 corresponds to the RTP basic header 
receiver/interpreter in the above-described embodiments. 

In theMPEG4 distribution server 6101 , the inputted AV content 
(for example, an analog signal) is compressed to MP EG 4 data by 
the MPEG4 data generator 6301. Required information is sent as 
notification to the MPEG4 payload header adding unit 6305 from 
the MPEG4 data generator 6301. 

Next , the MPEG4 data outputted from the MPEG 4 data generator 
6301 is encrypted by the data encrypter 6302. The encryption key 
used when doing this is the above-described time-variant encryption 
key Kc. Required information is sent as notification to the 
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encryption header adding unit 63 04 from the data encrypter 6302. 

Next, in the HTTP processor 6303 , at the encryption header 
adding unit 6304, the encryption expansion header is added, and 
at the MIME header adding unit 6306, a MIME header is added. 

Encrypted MPEG4 data to which has been added, a MIME header 
is sent as a packet shown in Fig. 32 to the Internet 6103 by the 
TCP/IP and UDP/IP processor 6308, via the link/physical layer 
processor 6309. 

In the receiving apparatus 6102, at the MIME header 
interpreter 6704, it is learned that there is a possibility that 
the received data is encrypted, and that an encryption expansion 
header is added as part of the MIME. At the encryption header 
interpreter 6706 it can be learned from the encryption expansion 
header whether or not encryption is present, the encryption system 
and whether the encryption key is updated. In the same manner 
as in the case of the second embodiment, the data 
encrypt or /decrypt or 6 707 decrypts the encrypted MPEG 4 data, at 
the MPEG4 payload header interpreting section 6715 the MPEG 4 payload 
header ( similar to the MPEG4 payload header in previously described 
embodiments) is interpreted, and at the MPEG 4 data generator 6708 
the MPEG4 data is decoded based on the results of the above 
interpretation, the result being output as an AV output data (for 
example, an analog signal). 

In the above , the encryption expansion header is added as 
an expansion header and the MPEG 4 expansion header was provided 
as a payload header on the payload. However, it is also possible 
to use a different configuration, for example one in which the 
encryption expansion header and MPEG4 expansion header are added 
as an expansion header, or in which the encryption expansion header 
and MP EG 4 expansion header are provided as a payload header on 
the payload. 

While in the first to seventh embodiments an Even/Odd field 
in the encryption expansion header (or encryption payload header) 
was used to notify the receiving side from the sending side of 
updating of the variable value Nc used for generating the encryption 
key Kc, instead of using the Even/Odd field, it is possible to 
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send the value of Nc, in which case the Nc value can be randomly 
generated, as opposed to simply being incremented. The value of 
Nc can also be changed for each individual packet. 

While in the first to seventh embodiments RTP or HTTP was 
used as the transfer protocol, it will be understood that other 
protocols can also be used, and further that the network to which 
the present invention is applied is not limited to the Internet. 
For example, any kinds of local area network, such as Bluetooth, 
can use the methods of this invention. Further, the present 
invention has no restriction in application to the case in which 
the transferred data is MPEG4 data. 

Although in the second, third, and fifth embodiments, the 
data encrypt or 302 and data encryptor /decrypt or~70 7 were provided 
outside the RTP processors 303 and 307, these can alternately be 
provided within the RTP processors 303 and 307. 

Eighth Embodiment 

Next, the eighth embodiment of the present invention is 
described below with reference to Fig. 35. 

Whereas in the first to the seventh embodiments, the 
description was for the sequence shown in Fig. 2, it is understood 
that the present invention can be applied to other sequences as 
well. 

The description that follows is for other sequences, for 
the case in which MPEG4 data distributed from an MPEG4 distribution 
server is stored by the receiving apparatus. 

The configuration of the information distribution system 
according to the eighth embodiment is similar to that shown in 
Fig. 1 . In Fig. 1 , an MPEG4 distribution server 101 and a receiving 
apparatus 102 according to the eighth embodiment are connected 
to the Internet 103, MP EG 4 AV stream data being secretly 
communicated between the MPEG4 distribution server 101 and the 
receiving apparatus 102, via the Internet 103. Of course, other 
MPEG4 distribution servers and receiving apparatuses and other 
types of equipment can additionally be connected to the Internet 
103. 
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In the description of the eighth embodiment, while the type 
of data is MPEG4, it will be understood that the eighth embodiment 
is not restricted to application to this type of data, and can 
be applied to other data types as well. 

The MPEG 4 distribution server 101 performs distribution of 
MP EG 4 data to the receiving apparatus 102. MPEG4 data is 
distributed not in the form of file transfer , but rather as a stream . 
When this is done, the MP EG 4 data that is to be copyright protected 
is distributed in encrypted form. Before distribution, an 
authentication procedure or key exchange procedure is performed 
between the MP EG 4 distribution server 101 and the receiving 
apparatus 102. 

An example of the sequence used is shown in Fig. 35. 

In Fig. 35 shows the sequence of content layer encryption 
and authentication, and it should be noted that security in layers 
such as the IP layer and transport layer and authentication 
procedures in those layers have been omitted from this drawing, 
as has the procedure for assessing charges at the content layer, 
which is performed earlier ( although there are cases in which charge 
assessment and authentication/encryption at other layers are not 
performed) . 

Similar to the case of the first embodiment, the MPEG4 
distribution server 101 and the receiving apparatus 102 perform 
authentication and exchange of a certificate (equipment 
certificate) (S7201 , S7202) . 

The MPEG4 distribution server 101 must notify the receiving 
apparatus 102 of the encryption key Kc for decrypting the content 
(AV data that is sent) , and the following measure is taken to prevent 
the unlimited unauthorized copying of the content at the receiving 
apparatus 102. Specifically, when performing storage onto a 
storage medium (for example, a DVD-RAM) of the receiving apparatus 
102, AV data is stored in encrypted form. When the data stored 
on the storage medium is to be played back, a check is made as 
to whether the data was properly stored on the storage medium and, 
if not, playback is not possible. That is, if digital copying 
is done from this storage medium onto another storage medium (for 
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example, onto another DV-RAM) , playback is prevented from the 
copying destination medium. 

For this reason, notification of the MID, which is the ID 
(serial number) of the storage medium used at the receiving 
apparatus 102 is given from the receiving apparatus 102 to the 
MP EG 4 distribution server 101 (step S7203), and at the MPEG4 
distribution server 101 this MID value is used to encrypt the 
encryption key Kc and notify the receiving apparatus 102 (step 
S7204). More specifically, using a pre-established function g 
an encryption key W is generated of the form W=g(MID), and this 
encryption key W is used to encrypt the encryption key Kc (the 
encryption key Kc encrypted by the encryption key W being 
represented as [Kc]w), [Kc]w being then transmitted. In this 
arrangement, the value of MID is uniq uejbp_eaQh„indi yidual stora ge 
medium, and is located in a region of ROM, for example, that cannot 
'be overwritten. 

Having received the above-noted [Kc]w # the receiving 
apparatus 102 generates the encryption key W in the form W=g(MID) , 
using the same function g that was used at the MP EG 4 distribution 
server 101, this encryption key W being used to decrypt [Kc]w so 
as to recover the encryption key Kc. 

Thereafter, at the MPEG 4 distribution server 101 MP EG 4 data 
is generated from the AV data, and MP EG 4 data is encrypted using 
the encryption key Kc shared as described above, the encrypted 
MPEG4 data being then transmitted to the receiving apparatus 102 
(step S7206) . 

At the receiving apparatus 102 , the received encrypted MPEG4 
data is decrypted using the encryption key Kc determined as noted 
above and decrypted MPEG4 data is decoded, resulting in output 
of an AV output data. 

In the eighth embodiment, the receiving apparatus 102 has 
a function which, simultaneously with receiving the AV data (MPEG4 
data encrypted with the encryption key Kc ) , or after entering it 
into a buffer or the like, stores the received AV data in the form 
of MPEG4 data encrypted using the encryption key Kc, along with 
the value of [Kc]w, onto a storage medium having the above-noted 
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MID . 

When the above is done, an apparatus for playing back the 
AV data (MPEG4 data encrypted with the encryption key Kc) stored 
on the proper storage medium (which can be the receiving apparatus 
102, or another equipment) first reads the values of [Kc]w and 
MID from the storage medium, and then generates the encryption 
key W in the form W=g(MID) , this encryption key W being used to 
decrypt [Kc]w so as to recover the encryption key Kc. Then the 
AV data (MPEG4 data encrypted by the encryption key Kc) stored 
on the storage medium is read out and, after decrypting with the 
encryption key Kc, the decrypted MPEG4 data is decoded. 

If AV data (MPEG4 data encrypted by the encryption key Kc) 
recorded on a storage medium having a given MIDof MIDI is copied 
onto a storage medium having a MID of MID2 , at the equipment that 
plays back the data recorded on the copy destination storage medium, 
because it is not possible to obtain the original MID value, it 
is not possible to generate W, and therefore not possible to 
determine the encryption key Kc from the recorded [Kc]w. As a 
result, it is not possible to decrypt the recorded encrypted data. 

That is, if proper values of Kc, W, and [Kc]w are Kcl, 
Wl=g(MIDl), and [Kc]wl, because the MID read out from the copy 
destination storage medium is MID2 , the encryption key W generated 
therefrom is W2=g(MID2) and if the [Kc]wl read from the storage 
medium is decrypted using W2, a value that is different from Kc 
results (this being called Kc' ) . Therefore, an attempt to decrypt 
data [ Data ]Kc encrypted with Kc using Kc' will result in generation 
of Data' , which is different from the original data Data, making 
it impossible to recover the original data Data. 

Thus, even if the received AV data (MPEG4 data encrypted 
by the encryption key Kc) is copied onto a different storage medium, 
because the value of MID of that storage medium is different, it 
is possible to prevent playback of the AV data, thereby enabling 
prevention of unauthorized copying. 

In the eighth embodiment, the RTP header, encryption 
expansion (payload) header, and MPEG4 expansion (payload) header 
and the like can have the same format as described with regard 
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to the first through the seventh embodiments. 

Although the above- noted description is for the case in which 
MP EG 4 was used as the encoding system, it will be understood that 
the present invention can be applied to other encoding systems 
as well, in which case it is merely necessary to modify the 
constituent elements of each of the embodiments (for example, the 
MP EG 4 data generator, the MPEG4 expansion header adding unit, the 
MPEG4 data decoder, the MPEG4 expansion header 

receiver/interpreter , and the like), the expansion header (MPEG4 
expansion header and MPEG 4 payload header) , and the payload type 
coding to suit the selected type of encoding system. 

The distribution server of the described embodiments, if 
necessary, can also be made to send content in unencrypted form. 
That is, the coding of the encryption on/off field and payload 
type field and the like can be established as appropriate to the 
existence or non-existence of encryption. The receiving side as 
well can check for the presence of encryption from the header of 
a received packet, and control decryption processing accordingly. 

The transport protocol used in the foregoing embodiments 
includes at least RTP or HTTP. 

The present invention can also be embodied as a method and 
a method according to the present invention can be embodied as 
an apparatus. Additionally, the functions of the present 
invention can be embodied as software as well. 

The present invention embodied as either an apparatus or 
a method can be further embodied as a computer- readable storage 
medium for storage of a program to be executed by a computer, 
following a procedure corresponding to the present invention (or 
a program for causing a computer to function as a means corresponding 
to the present invention or a program for implementing the functions 
of the present invention with a computer). That is, a program 
for the purpose of implementing the processing for content 
distribution and receiving according to the present invention can 
be stored onto various types of storage media. The storage medium 
is then read by the CPU of a computer implemented in hardware, 
and the stored program is then executed to embody the present 
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invention. The term storage medium used herein can be taken as 
referring to semiconductor memory, magnetic disk (floppy disk or 
hard disk) , optical disk (CD-ROM or DVD or the like) , and any other 
medium that can be used to store a program. Additionally, the 
program can be distributed by various communications means, such 
as a network. 

In summary, according to the present invention an encryption 
expansion header is provided in the form of a expansion header 
or pay load header in a transport protocol such as RTP (Real-time 
Transport Protocol) or HTTP (Hyper- text Transfer Protocol), and 
encryption attribute information with regard to encryption is coded 
into this encryption- expansion header (for example, presence of 
encryption, encryption system, information with regard to copying 
(encryption mode indicator: EMI), information (Even/Odd field) 
on which to base generation of a content key (common key) and the 
like ) , and by doing so content data is sent securely from the sending 
side to the receiving side, and it is possible at the receiving 
side to decrypt the encrypted content data transferred as a payload . 

In RTP in the past, only the type of encoding system used 
with data of the payload was coded in the payload type field, so 
that in the case in which the data stored in the payload was encrypted 
not in at the network or transporter layer, but rather at the content 
layer, there was no method of giving notification of this to the 
other side. 

On the other hand, with the present invention , because coding 
is provided in the RTP payload type field to the effect that the 
content is "encrypted data" or "encrypted data encoded by a specif ic 
encoding system", it is possible to give notification of this to 
the other side, thereby enabling sufficient copy protection in 
sending and receiving encrypted content as described above. 

According to the present invention as described above, it 
is possible to expand the distribution of digital content , providing 
copy protection for AV streaming that covers not only IEEE 1394, 
but also networks such as the Internet and LAN. 

It is to be noted that , besides those already mentioned above , 
many modifications and variations of the above embodiments may 
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be made without departing from the noel and advantageous features 
of the present invention. Accordingly, all such modifications 
and variations are intended to be included within the scope of 
the appended claims. 
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